home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / files / tcpip / amiga / mb1705.exe / BID.DOC < prev    next >
Encoding:
Text File  |  1994-04-24  |  4.7 KB  |  138 lines
  1. BID.DOC
  2.  
  3. There is a "BID" (Bulletin IDentifier) associated with each bulletin
  4. type message and with any message which has a distribution list.
  5.  
  6. If a BID is not given explicitly with the "Send" command, one is
  7. created automatically from the message number and callsign of the MailBox
  8. into which the message was initially entered. It has the form callnnn,
  9. where nnn is the message number at the originating bbs and will not exceed
  10. 12 characters in length.
  11.  
  12. The BID must always be sent with the mesage, and may not be changed.
  13.  
  14. There are 3 types of messages:
  15.  
  16. 1) Personal.
  17.  
  18. 2) NTS traffic.
  19.  
  20. 3) Bulletins.
  21.  
  22. For Bulletins, a BID is ALWAYS associated with the message, and is sent when
  23. forwarding to systems that indicate in their SID that they accept BIDs.
  24.  
  25. For Personal, the message NEVER has a BID, unless the sender specifies one.
  26.  
  27. For NTS traffic, there is NEVER a BID.
  28.  
  29. There are several "flags" associated with each message.  These are shown in
  30. the "message status" position in the "list message" display.  Note that each
  31. flag has an associated "L" command, and some have associated "K" commands.
  32.  
  33.    F - The "Forwarded" flag:
  34.  
  35.        This indicates the message has been forwarded to all
  36.        its destinations, but has not yet been killed.
  37.  
  38.    H - The "Hold" flag:
  39.  
  40.        This indicates the message is held.
  41.        It will not forward, and can only be seen by the sysop.
  42.  
  43.    I - The "In process" flag:
  44.  
  45.        This indicates the message is in the process of being forwarded.
  46.  
  47.    K - The "Killed" flag:
  48.  
  49.        This indicates the message is killed, but has not yet been purged
  50.        from the system.  Killed messages are purged with the GM command.
  51.  
  52.    M - The "Mine" flag:
  53.  
  54.        This indicates that the message orginated at this system.
  55.  
  56.    O - The "Old" flag:
  57.  
  58.        This indicates the message has been hanging around
  59.        un-forwarded and un-read for too long.
  60.  
  61.    Y - The "Read" flag:
  62.  
  63.        This indicates the message has been read by its addressee,
  64.        but has not yet been killed.
  65.  
  66.    R - The "Read Bulletin" flag:
  67.  
  68.        This indicates the bulletin has been read by the sysop.
  69.  
  70. How do BID's work?
  71.  
  72. The various commands (S, M, CM) work in exactly the same way.
  73. The basic command is S[type] TO [@ AT[.LOC]] [< FROM] [$[BID]]
  74. Data inside [] may be omitted.
  75.  
  76. Messages differ in the following ways:
  77.  
  78.    TO may be translated.
  79.    TO is a callsign.
  80.    TO is an interest group.
  81.    AT may be translated.
  82.    AT is a callsign.
  83.    AT is a distribution list.
  84.    $ field is present.
  85.    $ field is present, with BID.
  86.    Type is B
  87.    Type is P
  88.    Type is T
  89.    Type was not specified.
  90.    Message is held.
  91.  
  92. A type B or P message gets a BID if the command that creates the message
  93. has the "$" field.  A message of type B gets a default BID if none was
  94. specified.  A message of type P gets a default BID if none was specified
  95. and it has a distribution list.  A message of type T never gets a BID.
  96. In the discussion below, the same rules apply whether the message was created
  97. using the S, M, or CM commands.
  98.  
  99. Here is how the system behaves:
  100.  
  101. 1) If the user sends the message with "$ID" given in the command,
  102.    the message is assigned identifier "ID".  If this identifier
  103.    has been seen before, the message is rejected and the text
  104.    "NO - Duplicate BID" is displayed.
  105.  
  106. 2) If the user sends the message with "$" given in the command,
  107.    the message is assigned a unique MailBox generated BID.  This BID
  108.    is generated from the message number and callsign of the MailBox.
  109.    The message is accepted, since this BID cannot have been seen before.
  110.  
  111. 3) If there is a distribution list, and a BID is not given with the command,
  112.    a unique MailBox generated BID is assigned.    This BID is generated from the
  113.    message number and callsign of the MailBox OF ORIGIN.  If this BID has been
  114.    seen before, the message is put on hold.
  115.  
  116. 4) If a message is received from another MailBox, and has a BID
  117.    sent along with it, and has a distribution list that includes
  118.    the MailBox from which the message was received, the message is
  119.    marked as already forwarded to that MailBox.
  120.  
  121. Some results of applying these rules:
  122.  
  123. 1) A message entered into the system without using "$" in the command
  124.    and without a distribution list may loop within the network.
  125.    These messages are held after they have passed through the system
  126.    a small number of times, normally two.
  127.  
  128. 2) A message which was entered with a "$" given in the command
  129.    will be rejected when it is forwarded back to any system it
  130.    previously passed through.
  131.  
  132. 3) Messages of type B or P may have a distribution list,
  133.    messages of type T may not.
  134.  
  135. 4) There will be no attempt to pass a message which has a BID
  136.    back to the station that sent it to you.
  137.  
  138.